Panic Error „range end index 4 out of range“ nach Vaultwarden Update – gelöst

Ich hab Vaultwarden auf meinem Server aktualisiert – von 1.33.2-alpine auf 1.34.2-alpine. Wie immer: docker compose pull, dann up -d, fertig.

Im gleichen Zug habe ich auch den MySQL-Container aktualisiert. Ich nutze das Image mysql:8 und habe auf die Version 8.4.6 aktualisiert. Welche Version vorher lief, weiß ich leider nicht genau – aber es war auf jeden Fall ebenfalls ein 8er-Release. Eigentlich also ein recht harmloses Update… sollte man meinen.

Vaultwarden startete danach ganz normal. Die Login-Seite war erreichbar, und ich konnte meine E-Mail-Adresse eingeben. Soweit, so gut – dachte ich.

Doch nach der Eingabe des Passworts im Webinterface knallte es richtig:

[2025-07-27 22:09:38.912][panic][ERROR] thread 'rocket-worker-thread' panicked at 'range end index 4 out of range for slice of length 0':
/root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/diesel-2.2.12/src/mysql/value.rs:69
   0: vaultwarden::init_logging::{{closure}}
   1: std::panicking::rust_panic_with_hook
   2: std::panicking::begin_panic_handler::{{closure}}
   3: std::sys::backtrace::__rust_end_short_backtrace
   4: __rustc::rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::slice::index::slice_end_index_len_fail::do_panic::runtime
   7: core::slice::index::slice_end_index_len_fail
   8: diesel::mysql::value::MysqlValue::numeric_value
   9: diesel::mysql::types::primitives::<impl diesel::deserialize::FromSql<
        diesel::sql_types::Integer,
        diesel::mysql::backend::Mysql
      > for i32>::from_sql
  10: <T as diesel::deserialize::FromStaticSqlRow<ST, DB>>::build_from_row
  11: <diesel::query_dsl::load_dsl::private::LoadIter<U, C, ST, DB> as core::iter::traits::iterator::Iterator>::next
  12: core::iter::traits::iterator::Iterator::collect
  13: vaultwarden::db::models::cipher::Cipher::find_by_user::{{closure}}::{{closure}}
  14: vaultwarden::db::models::cipher::Cipher::find_by_user::{{closure}}
  15: vaultwarden::db::models::cipher::Cipher::find_by_user_visible::{{closure}}
  16: vaultwarden::api::core::ciphers::sync::into_info::monomorphized_function::{{closure}}
  17: rocket::server::<impl rocket::rkt::Rocket<rocket::phase::Orbit>>::route::{{closure}}
  18: rocket::server::hyper_service_fn::{{closure}}::{{closure}}
  19: tokio::runtime::task::raw::poll
  20: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
  21: tokio::runtime::scheduler::multi_thread::worker::run
  22: tokio::runtime::task::raw::poll
  23: std::sys::backtrace::__rust_begin_short_backtrace
  24: core::ops::function::FnOnce::call_once{{vtable.shim}}
  25: std::sys::pal::unix::thread::Thread::new::thread_start

🧪 Symptome: Merkwürdiges Verhalten auch bei Browser & App

Parallel zur Weboberfläche habe ich auch die Browser-Erweiterung getestet – und da war ebenfalls einiges kaputt. Normalerweise bleibe ich dort eingeloggt, aber diesmal wurde ich direkt ausgeloggt. Der erneute Login klappte zwar, aber danach war mein Tresor komplett leer. Kein einziger Eintrag zu sehen – was ehrlich gesagt schon ziemlich beunruhigend war.

Komisch war nur: Die Windows-App funktionierte weiterhin ganz normal. Ich konnte mich einloggen und alles war da. Das Verhalten war also nicht nur inkonsistent – es war richtig irreführend. Und das machte die Fehlersuche umso schwieriger.

🔍 Ursache: Ein unscheinbares Feld mit großer Wirkung

Nach etwas Recherche bin ich in einer GitHub-Diskussion (Vaultwarden #5959) auf genau meinen Fehler gestoßen. Dort wird beschrieben, dass in der Tabelle ciphers das Feld reprompt bei manchen Einträgen NULL sein kann. Vaultwarden erwartet dort aber zwingend einen Integer – ist NULL drin, scheitert die Deserialisierung durch die Rust-Library diesel mit einem Panic Error.

In meinem Fall war genau das die Ursache – und ließ sich mit einem SQL-Statement sauber beheben.

Es lohnt sich aber zu erwähnen:
In der Diskussion wird auch auf weitere mögliche Ursachen hingewiesen. Dazu gehören z. B.:

• Nicht vollständig durchgeführte Schema-Änderungen
• Falsche Zeichencodierung (Charset) oder Collation

Wenn du also ein ähnliches Fehlerbild hast, aber reprompt bei dir korrekt gesetzt ist, dann solltest du dir zusätzlich die Datenbank-Collation und -Charset anschauen. Die Vaultwarden-Doku enthält dazu auch einen passenden Abschnitt:
🔗 MySQL Backend – Charset und Collation prüfen

Außerdem wichtig: Das Problem scheint vor allem Alpine-/musl-basierte Vaultwarden-Images zu betreffen. Wer ein Debian-basiertes Image verwendet, ist nach aktuellem Stand nicht betroffen. Auch der Entwickler selbst hat sich bereits dazu geäußert und angekündigt, das Verhalten gezielt zu reproduzieren und in den musl-Builds zu fixen. (Stand: 28.07.2025)

🧯 Die Lösung: Ein einzelnes SQL-Statement

Mein erster Gedanke war: Ich logge mich in den MySQL-Container ein und repariere das per Hand. Gesagt, getan… dachte ich. Ich habe versucht, mich mit dem vaultwarden-Benutzer anzumelden – aber das schlug fehl mit der Fehlermeldung:

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

Also hab ich’s mit dem root-Benutzer versucht – und siehe da: das klappte sofort. Manchmal ist der Vorschlaghammer halt doch die beste Lösung.

In der MySQL-Konsole hab ich meine Vaultwarden-Datenbank ausgewählt:

SHOW DATABASES;
USE vaultwarden;

Dann habe ich die NULL-Werte in der Spalte reprompt auf 0 gesetzt:

UPDATE `ciphers` SET `reprompt` = 0 WHERE `reprompt` IS NULL;

Ein schneller Check mit SELECT ROW_COUNT(); zeigte mir, dass tatsächlich mehrere Zeilen betroffen waren. Anschließend habe ich den Login erneut ausprobiert – und siehe da: Der Login im Webinterface funktionierte wieder wie gewohnt. Auch die Browser-Erweiterung zeigte wieder meine Einträge, und alles war an seinem Platz.

✅ Fazit

Das hier ist mal wieder ein gutes Beispiel dafür, warum man Tools nicht einfach automatisch updaten lassen sollte – zumindest nicht blind. In meinem Fall zählt Vaultwarden ganz klar zur kritischen Infrastruktur. Wenn dieses Update still im Hintergrund gelaufen wäre, hätte ich den Fehler wahrscheinlich gar nicht mitbekommen – bis irgendwann die ersten Rückmeldungen gekommen wären, dass Logins nicht mehr funktionieren.

Automatisierung ist praktisch, keine Frage. Aber gerade bei sicherheitsrelevanten Anwendungen sollte man immer nochmal selbst einen Blick drauf werfen. Ein kurzer Check nach dem Update kostet fast nichts – kann aber eine Menge Frust ersparen.

👥 Techniverse Community

Matrix, Selfhosting, smarte IT-Lösungen und jede Menge Nerd-Talk – das findest du in der Techniverse Community.
Komm vorbei, tausch dich aus und werde ein Teil von uns.
👉 Unsere Gruppe auf Matrix: #community:techniverse.net
Wir freuen uns auf dich!